The Secure Shell (SSH) protocol is one of the most widely used cryptographic protocols today. SSH is frequently used for remote administration, secure file transfers, backups, and process-to-process communication. Given that IPSec operates on the packet level and is mostly applicable for Virtual Private Networks, not so much for application-level connections, and that the Secure Sockets Layer (SSL) (and its newer version, the Transport Layer Security (TLS) protocol) are suffering from fundamental security problems (particularly, their dependence on certificates and PKI for authentication, and breach of any certificate authority (CA) key in the world allows a certificate to be created for any user or host), the use of the SSH protocol can be reasonably expected to increase in the future.
The SSH protocol is described in the Internet Engineering Task Force (IETF) standards RFC 4250 The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4251 The Secure Shell (SSH) Protocol Architecture, RFC 4252 The Secure Shell (SSH) Authentication Protocol, RFC 4253 The Secure Shell (SSH) Transport Layer Protocol, and RFC 4254 The Secure Shell (SSH) Connection Protocol. The original protocol was invented and developed by the present inventor in 1997-1999, and then standardized by the IETF. The above mentioned RFCs are hereby incorporated herein by reference in their entirety. They are freely available for download at www.ietf.org.
The SSH protocol and related client and server software applications are now included in nearly all Unix and Linux versions, such as IBM AIX, HP-UX, Solaris, Red Hat, SUSE, Ubuntu, etc. Popular implementations of the SSH protocol include the open source OpenSSH, which is based on the present inventor's free SSH version 1.12 from 1995, and the commercial Tectia SSH client (also called ssh.com SSH) and server from SSH Communications Security (Tectia Corporation).
The largest enterprises in the world have hundreds of thousands of computers and up to about a hundred thousand servers running various versions of Unix, Linux, and Windows operating systems on their network. Large enterprises commonly run thousands of different business applications that interact with each other and transmit data and files to/from each other in an automated fashion. A large enterprise typically has tens of thousands of hosts running SSH servers.
In this specification, a host means a computer (whether client or server or something else), or computing node on a network, typically having an IP address and name (though some hosts have more than one IP address (IPv4 or IPv6) and/or name, and some may not have a name at all; typically the names are stored in DNS, the Domain Name System, and/or Active Directory or WINS (NBNS)). A host can also be a virtual machine (e.g., running under WwWare).
To automate file transfers and other communication between computers and applications, companies typically use public key authentication according to the SSH protocol. Public key authentication and how to set it up is described in RFC 4252 and the books D. Barrett et al: SSH, the Secure Shell: The Definitive Guide, O'Reilly, 2001; H. Dwivedi: Implementing SSH: Strategies for Optimizing the Secure Shell, Wiley, 2004; and A. Carasik: Unix Secure Shell, McGraw-Hill, 1999; which are hereby incorporated herein by reference.
Generally, public key authentication is just one method for implementing passwordless logins. A passwordless login is a mechanism whereby a program running under a user account on one host can gain access to a second account on another machine (though they could also be the same account and same machine), without needing to have an interactive user supply a password. Other mechanisms could include, e.g., hard-coding a password or supplying it on a command line. However, with the SSH protocol the public key authentication is usually the preferred method, because with it one cannot gain access to the private key (the authentication credential in this case) from the second account. In some cases, host based authentication and Kerberos authentication can also be used for passwordless logins.
Some organizations use public key authentication to grant authorizations and access rights to individual users. A user is given authorization to log into certain accounts based on the user's role. For example, an Oracle administrator might be given a private key that authorizes the administrator to log into any Oracle database account in his/her department. When a user's role changes, the old access rights would be removed and new ones might be added in accordance with the new role. Removing the user's access basically means de-authorizing the access.
Yet another use of public key authentication is to allow administrators to log into shared accounts on jump servers that can then be used to access numerous other systems, such as point-of-sale terminals in a retail environment.
In large organizations, the number of different file transfers and authentications that they manage grows very large, and such organizations typically have hundreds of system administrators each managing some hundreds of computers. It is very difficult for security administrators to keep track of what authorized public key login connections exist, what each connection is used for, and when the connection can/should be removed. It is currently practically impossible for organizations to renew the authentication keys, which any prudent security practice would require. Furthermore, there is currently no practical way for the organizations to prevent an administrator from copying the private key, and continuing to use the private key after changing roles or leaving the job, and many organizations never remove authorized public keys because it is too difficult and expensive.
Some large enterprises are known to have over a hundred thousand public-private key pairs used as SSH authentication keys. Many large enterprises have sizable teams setting up SSH authentication keys. The problem appears to be present in nearly all F500 companies and many of the next 10 000 large companies. Therefore, the combined cost of managing key pairs and authorizations in large enterprises worldwide is substantial.